The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Computer programs that operate on servers that are accessible over the public Internet, and in other contexts, are known to have vulnerabilities to various kinds of attacks. Certain attacks are implemented by installing unauthorized or malicious code into the programs and causing execution of the foreign code.
Virtualization is a technique with which multiple different host operating systems, with associated computer programs, can run on a single computer or processor under control of a supervisory program, which may be a hypervisor. The use of virtualization creates new opportunities for attacks and new kinds of security vulnerabilities.
The SecVisor academic research project uses permissions bits maintained in an operating system page table to determine whether a page is writable or executable and to set page permissions so that pages of program code are not executable if they are also writable. However, SecVisor provides no mechanism for interworking with the memory page permissions that are maintained in a hypervisor or in a virtual machine monitor (VMM) that is closely coupled to a virtualization-optimized CPU, such as Xen on Intel processors.
Xen has provided the ability for a privileged domain to register on a hypercall interface for a memory event that is served by the memory handler of the hypervisor. Memory events have been used for demand paging of the domain, for example, for disk swapping of memory pages. Programs listening on memory events could use a different hypercall to read or write pages from or to disk and update page type values to indicate that the pages have been paged in or out. Xen implements a memory page framework denoted p2m that manages memory page type values for the purpose of supporting different uses of memory. For example, when a memory page has been paged out to disk, the memory page type value for that page may be set to “swapped out” (p2m_ram_paged) because the page is unavailable. This type is then converted to a memory access permission of not-readable. If a program attempts to read the page, Xen p2m throws a page fault and its page fault handler will page the memory in from disk, update the memory page type value to a paged-in type (which is converted to an access permission of readable), and return control to the program that caused the fault. Additional memory types exist for pages that are emulating hardware—and thus should cause the I/O emulator to react as if the memory access were a bus access to a peripheral. Additional page types are for shared memory between domains. However, none of the page types represent access permissions different from their type or usage, and thus make altering or restricting memory access permissions further for security—for example, of the content, rather than the emulation purpose—of the page impossible.